home *** CD-ROM | disk | FTP | other *** search
-
-
-
- cccc((((3333GGGG)))) cccc((((3333GGGG))))
-
-
-
- NNNNAAAAMMMMEEEE
- cccc3333ffff,,,, cccc3333iiii,,,, cccc3333ssss,,,, cccc4444ffff,,,, cccc4444iiii,,,, cccc4444ssss - sets the RGB (or RGBA) values for the
- current color vector
-
- CCCC SSSSPPPPEEEECCCCIIIIFFFFIIIICCCCAAAATTTTIIIIOOOONNNN
- vvvvooooiiiidddd cccc3333ssss((((ccccvvvv))))
- sssshhhhoooorrrrtttt ccccvvvv[[[[3333]]]];;;;
-
- vvvvooooiiiidddd cccc3333iiii((((ccccvvvv))))
- lllloooonnnngggg ccccvvvv[[[[3333]]]];;;;
-
- vvvvooooiiiidddd cccc3333ffff((((ccccvvvv))))
- ffffllllooooaaaatttt ccccvvvv[[[[3333]]]];;;;
-
- vvvvooooiiiidddd cccc4444ssss((((ccccvvvv))))
- sssshhhhoooorrrrtttt ccccvvvv[[[[4444]]]];;;;
-
- vvvvooooiiiidddd cccc4444iiii((((ccccvvvv))))
- lllloooonnnngggg ccccvvvv[[[[4444]]]];;;;
-
- vvvvooooiiiidddd cccc4444ffff((((ccccvvvv))))
- ffffllllooooaaaatttt ccccvvvv[[[[4444]]]];;;;
-
- The subroutines above are functionally the same but declare their
- parameters differently.
-
- PPPPAAAARRRRAAAAMMMMEEEETTTTEEEERRRR
- _c_v For the cccc4444 routines, this parameter expects a four element array
- containing RGBA (red, green, blue, and alpha) values. If you use
- the cccc3333 routines, this parameter expects a three element array
- containing RGB values.
-
- Array components 0, 1, 2, and 3 are red, green, blue, and alpha,
- respectively. Floating point RGBA values range from 0.0 through 1.0.
- Integer RGBA values range from 0 through 255. Values that exceed
- the upper limit are clamped to it. Values that exceed the lower
- limit are not clamped, and therefore result in unpredictable
- operation.
-
- DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
- cccc4444 sets the red, green, blue, and alpha color components of the currently
- active GL framebuffer, one of normal, popup, overlay, or underlay (see
- ddddrrrraaaawwwwmmmmooooddddeeee). cccc3333 sets red, green, and blue to the specified values, and
- sets alpha to the maximum value. The current framebuffer must be in RGB
- mode (see RRRRGGGGBBBBmmmmooooddddeeee) for the cccc command to be applicable. Most drawing
- commands copy the current RGBA color components into the color bitplanes
- of the current framebuffer. Color components are retained in each draw
- mode, so when a draw mode is re-entered, red, green, blue, and alpha are
- reset to the last values specified in that draw mode.
-
-
-
-
-
-
- PPPPaaaaggggeeee 1111
-
-
-
-
-
-
- cccc((((3333GGGG)))) cccc((((3333GGGG))))
-
-
-
- Integer color component values range from 0, specifying no intensity,
- through 255, specifying maximum intensity. Floating point color
- component values range from 0.0, specifying no intensity, through 1.0,
- specifying maximum intensity.
-
- It is an error to call cccc while the current framebuffer is in color map
- mode.
-
- The color components of all framebuffers in RGB mode are set to zero when
- ggggccccoooonnnnffffiiiigggg is called.
-
- SSSSEEEEEEEE AAAALLLLSSSSOOOO
- cpack, drawmode, lmcolor, gRGBcolor
-
- NNNNOOOOTTTTEEEE
- These routines can also be used to modify the current material while
- lighting is active (see llllmmmmccccoooolllloooorrrr). Note that clamping to 1.0 is disabled
- in this case.
-
- Because only the normal framebuffer currently supports RGB mode, cccc should
- be called only while draw mode is NNNNOOOORRRRMMMMAAAALLLLDDDDRRRRAAAAWWWW. Use ggggeeeettttggggddddeeeesssscccc to determine
- whether RGB mode is available in draw mode NNNNOOOORRRRMMMMAAAALLLLDDDDRRRRAAAAWWWW.
-
- BBBBUUUUGGGGSSSS
- On the IRIS-4D/120GTX and IRIS-4D/140GTX, there is problem with the
- graphics DMA hardware that can cause data to be sent to the hardware
- after the subroutine call has returned. If the data is modified
- immediately after the subroutine call, the modified data may get sent
- down. To avoid this, don't modify the data until after another nnnn, vvvv, or
- cccc call has been made.
-
- This is an example of the bug:
-
- vertex[2] = 1.0;
- v3f(vertex); /* 4D/1x0 GTX hardware may receive 3.0 for the z value */
- vertex[2] = 3.0;
- v3f(vertex);
-
-
- This is one way to work around the problem:
-
- vertexA[2] = 1.0;
- v3f(vertexA);
- vertexB[2] = 3.0;
- v3f(vertexB);
-
-
-
-
-
-
-
-
-
-
- PPPPaaaaggggeeee 2222
-
-
-
-